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Description 

BACKGROUND OF THE INVENTION 

[0001] The present invention relates generally to a $ 
method and apparatus for emulating the execution of a 
program on a computer system. In particular, the 
present invention relates to monitoring program behav- 
ior to detect and terminate harmful or dangerous behav- 
ior in a program. More particularly, the present invention 10 
relates to monitoring program behavior to detect com- 
puter viruses. 

[0002] In recent years, the proliferation of "computer 
viruses" (generally designed by rogue programmers ei- 
ther maliciously or as "pranks") has become an increas- is 
ingly significant problem for the owners and users of 
computer systems. True computer viruses vary, but they 
share the general characteristic that they comprise ex- 
ecutable computer code capable of replicating itself by 
attachment to and modification of standard computer 20 
files. Such files are then considered "infected". On most 
computer systems, viruses are limited to infecting pro- 
gram applications. When the application is executed, 
the virus can then replicate and attach copies to further 
application files. Typically, viruses also engage in other 25 
forms of behavior that are considered undesirable, such 
as re-formatting a hard disk. 

[0003] Often grouped with true computer viruses are 
some other types of malevolent computer programs: 
worms and trojan horses. Worms do not infect other ap- 30 
plications but merely replicate, either in memory or in 
other storage media. The harmful effect of worms is gen- 
erally to reduce system performance. Worms are of con- 
cern for large multiuser computer systems, but are gen- 
erally not of concern for personal computers. Trojan 35 
horses are programs that masquerade as useful pro- 
grams or utilities; they generally run only once and have 
a harmful effect (such as destroying or damaging the 
computer system data storage). Trojan horses do not 
replicate, and after being run once by a user, the user *o 
is usually alerted to the harmful behavior and will not run 
the trojan horse again. 

[0004] In response to the proliferation of computer vi- 
ruses, a variety of "antivirus" methodologies and pro- 
grams have been developed to detect the presence of 
infected files. These antivirus programs can be gener- 
ally categorized into groups: behavior interceptors, sig- 
nature scanners, and checksum monitors. 

BEHAVIOR INTERCEPTORS 

[0005] The earliest antivirus programs were generally 
of the behavior interceptor type: they would allow a virus 
program to execute in memory but would intercept stra- 
tegic operating system function requests made by the ss 
computer virus. Such requests would generally be func- 
tions which the virus required to be performed in order 
to replicate or to destroy its host, i.e., "Write to a file", 



"Erase a file", "Format a disk" etc. By intercepting these 
requests, the computer operator/user could be informed 
that a potentially dangerous function was about to be 
performed. Control could be halted or continued as nec- 
essary. Some antivirus programs actually modify the in- 
structions of the discovered virus program and make 
them inoperable so as to "kill" them. 
[0006] The behavior interceptor method of virus de- 
tection has several drawbacks. The first problem is that 
it relies entirely on user input and decision making when 
potentially dangerous behavior is detected. This places 
a great burden on the user, for it is often very difficult to 
determine whether the flagged behavior is part of the 
normal operation of the program being executed. For 
example, disk optimizing programs routinely reformat 
hard disks to improve the interleave value. In response 
to a warning message, a user might suspect that their 
disk optimizer was infected with a virus (when in fact it 
was not) and halt program execution. Or, worse yet, if 
the user knows that such behavior is part of the normal 
operation of a disk optimizer program, they would likely 
allow the format to continue uninterrupted, which would 
be disastrous if the program were actually infected. 
[0007] A second problem with behavior interceptor 
antivirus programs is that computer virus technology 
has advanced to such a state that some computer vi- 
ruses are able to bypass the interception points used by 
the antivirus. The virus can then make operating system 
function requests that are never intercepted by the an- 
tivirus, thus avoiding detection. 
[0008] A third problem with behavior interceptor anti- 
virus programs is that by allowing the virus to execute, 
the virus has an opportunity to locate and identify the 
antivirus program in computer memory. Once the anti- 
virus program is located, the virus can modify the anti- 
virus- rendering it completely ineffective in exactly the 
same manner that antivirus programs locate and modify 
virus programs to render them ineffective. 
[0009] A fourth and very significant problem with be- 
havior interceptor antivirus programs is that there are 
no low level operating system function requests em- 
ployed by computer viruses that are not also used by 
any of thousands of non-virus programs. At an instruc- 
tion by instruction level, or at a function-call by function- 
call level, a computer virus performs the same opera- 
tions as legitimate computer programs. In other words, 
the closer a computer virus is examined, the less distin- 
guishable it becomes from any other computer program. 

SIGNATURE SCANNERS 

[0010] The next generation of antivirus technology, 
signature scanners, answered the problem of over-reli- 
ance on user interaction as well as the problem of al- 
lowing the virus to execute. A signature scanner oper- 
ates by knowing exactly what a target virus program 
code looks like ("signature" code) and then scanning for 
these program codes in any programs requested to be 
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executed or otherwise requested to be scanned. As long 
as the signature codes were sufficiently long enough so 
as not to be confused with another program's code, then 
positive identification was virtually guaranteed and the 
request to execute could be stopped before execution 
ever began. The primary problem with this technique is 
that it requires the antivirus developer to have previously 
collected and analyzed the target viruses, and included 
the signature codes in the antivirus program. The anti- 
virus program thus relies on an extensive virus signature 
library, for there are currently several thousand known 
IBM PC viruses and several new viruses appear each 
day. Any new viruses appearing after the antivirus pro- 
gram was developed are not included in the library of 
program codes for which the antivirus can scan. Signa- 
ture scanning antivirus programs therefore require fre- 
quent updates to keep them current with the increasing 
number of viruses. If the antivirus developer is lax in pro- 
viding updates, or the user is lax in obtaining and em- 
ploying available updates, a signature scanning antivi- 
rus program can rapidly lose its effectiveness. 

CHECKSUM MONITORS 

[001 1 ] The last standard technique of virus detection 
does not look for anything to do with viruses in particular, 
but concentrates on the host programs which the virus- 
es attack. Every program on a system can be "check- 
summed" at antivirus installation time. Then, when a vi- 
rus attaches itself to the unsuspecting host program, the 
checksum value will (probably) be different and the file 
infected with the virus can be isolated. The primary prob- 
lem with this technique is that many programs store var- 
ying program information within themselves; this will 
change the checksum value and thus trigger a false 
alarm virus detection. Another problem is ensuring the 
integrity of the checksum information, which is typically 
attaced to the program file itself or stored in a separate 
file. Both locations are vulnerable to covert virus modi- 
fication. Once a virus infects a host, it can then update 
the stored checksum value to correspond to the newly 
infected file and then execute undetected. 
[0012] IBM Technical Disclosure Bulletin Vol. 34, No. 
2, July 1991 pp 415-416 mentions the possibilty of de- 
tecting a computer virus by simulating the execution of 
a file to determine whether such execution would have 
resulted in the alteration of any executable or other ob- 
jects in the system or the execution of any self-altering 
code. 

[001 3] According to a first aspect of the present inven- 
tion, there is provided a computer system configured to 
monitor the execution of a target program, said compu- 
ter system comprising: 

a processing unit having an instruction set; 

an instruction emulator for emulating instructions 

corresponding to the instruction set; 

an entry point access controller for controlling ac- 
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cess to operating system entry points; 
a logger for logging improper access by said in- 
structions to operating system entry points; and 
an interrupt tester, wherein said interrupt tester ex- 
5 ecutes a guinea pig file and tests for modification of 
the guinea pig file to determine if a viral interrupt 
has been installed. 

[0014] According to a second aspect of the present 
10 invention, there is provided a computer system config- 
ured to monitor the execution of a target program, said 
computer system comprising; 

a processing unit having an instruction set; 

is an instruction emulator for emulating instructions 
corresponding to the instruction set; 
an entry point access controller for controlling ac- 
cess to operating system entry points; 
a logger for logging improper access by said in- 

20 structions to operating system entry points; and 

an interrupt tester, wherein said interrupt tester 
opens and closes a guinea pig file and tests for 
modification of the guinea pig file to determine if a 
viral interrupt has been installed. 

25 

[0015] According to a third aspect of the present in- 
vention, there is provided, in a computer system, a 
method for monitoring execution of a target program 
comprising the steps of; 

30 

- emulating instructions corresponding to the instruc- 
tion set of the target program; 

- controlling access to operating system entry points; 
logging improper access by said instructions to op- 

35 erating system entry points; and 

- monitoring emulation of the target program to detect 
a predetermined behaviour indicating presence of 
a virus, by: 

opening and closing a guinea pig file and test- 
40 ing for modification of the guinea pig file to deter- 
mine if a viral interrupt has been installed. 

[0016] According to a fourth aspect of the present in- 
vention, there is provided, in a computer system, a 
45 method for monitoring execution of a target program 
comprising the steps of: 

emulating instructions corresponding to the instruc- 
tion set of the target program; 
so - controlling access to operating system entry points; 

- logging improper access by said instructions to op- 
erating system entry points; and 

- monitoring emulation of the target program to detect 
a predetermined behaviour indicating presence of 

55 a virus, by: 

executing a guinea pig file and testing for 
modification of the guinea pig file to determine if a 
viral interrupt has been installed. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] Fig. 1 A is a block diagram illustrating the pri- 
mary components of a computer system executing a tar- 
get program in a standard manner. 5 
[0018] Fig. 1B is a block diagram illustrating the pri- 
mary components of a computer system executing a tar- 
get program according to the present invention. 
[001 9] Figs. 2A and 2B are diagrams illustrating mem- 
ory maps of the computer systems of Figs. 1 A and 1 B, 10 
respectively. 

[0020] Fig. 3 is a block diagram illustrating the register 
set emulated by a particular embodiment of the present 
invention. 

[0021] Figs. 4 A and 4B are flowcharts illustrating re- is 
spectively the installation and replication procedures 
typically employed by computer viruses. 
[0022] Fig. 5 is a flowchart illustrating the general em- 
ulation process performed by a monitor program ac- 
cording to a particular embodiment of the present inven- 20 
tion. 

[0023] Fig. 6 is a flowchart illustrating in further detail 
the memory access control step of the flowchart Fig. 5. 
[0024] Fig. 7 is a flowchart illustrating in further detail 
the procedure access control step of the flowchart of Fig. 25 
5. 

[0025] Fig. 8 is a flowchart illustrating in further detail 
the operating system entry point monitoring step of the 
flowchart of Fig. 5. 

[0026] Fig. 9 is a flowchart illustrating the process per- so 
formed by a particular embodiment of the present inven- 
tion to check the behavior of an interrupt handler. 
[0027] Fig. 10 is a flowchart illustrating the process 
performed by a particular embodiment of the present in- 
vention to identify viral replication behavior. & 
[0028] In Fig. 1 A a block diagram is shown illustrating 
the primary components of a computer system execut- 
ing a target program in a standard manner. The compu- 
ter system includes a CPU 1 0, a memory 20, and a disk 
storage device 30. This is simply an exemplary config- *o 
uration; the system could of course employ a tape stor- 
age device rather than disk storage, and many other var- 
iations are possible as well. Operating system 40 typi- 
cally exists in Read Only Memory, but may also be par- 
tially loaded from the disk storage 30 into memory 20. & 
At power up, the CPU begins executing the instructions 
of operating system 40, which thereafter controls the 
loading and execution of application programs such as 
target program 50. 

[0029] In this standard configuration, if a user selects so 
target program 50 for execution, operating system 40 
would load target program 50 from disk storage 30 into 
memory 20 and then transfer control to target program 
50 by loading the start address of target program 50 into 
the program counter register, or instruction pointer reg- ss 
ister, of CPU 10. CPU 10 would then begin executing 
the instructions of target program 50, as pointed to by 
the instruction pointer register. Target program 50 will 



typically include calls to operating system routines, 
which are identified by a table of pointers, commonly 
known as interrupt vectors. It is by remapping these in- 
terrupt vectors that standard behavior interceptor anti- 
virus programs attempt to maintain control and supervi- 
sion of target programs. As discussed above, however, 
many computer viruses are able to circumvent this rem- 
apping of the interrupt vectors and are able to use op- 
erating system routines without being monitored by the 
antivirus program. 

[0030] In order to prevent this circumvention of mon- 
itoring code, a particular embodiment of the present in- 
vention is invoked by a user to request that an applica- 
tion program be analyzed for viral behavior. This em- 
bodiment takes the form of a monitor program that em- 
ulates the execution of the application for a period of 
time, monitoring its behavior. By emulating the execu- 
tion of the application program, the application program 
can be maintained in a controlled environment that can- 
not be circumvented by a virus. 
[0031] The configuration of the monitor program and 
target application program is illustrated in Fig. 1 B. Mon- 
itor program 60 loads target program 50 into memory 
and emulates the execution of the instructions of target 
program 50, serving as a protective barrier between the 
application program and the remainder of the computer 
system. If the application program has not shown any 
viral behavior at the end of the monitor period, then it is 
loaded and executed in the standard manner, such as 
illustrated in Fig. 1A. 

[0032] In the secure environment created by the mon- 
itor program of Fig. 1B, every aspect of execution can 
be scrutinized and the operation of the virus can be con- 
trolled completely. If the virus were to request a hard 
disk format operation, a successfully completed status 
would be returned to it making the virus "believe" that 
the operation was successful when in fact it was never 
executed in the first place. 

[0033] Figs. 2A and 2B respectively show the general 
layout in memory 70 for an IBM PC type computer sys- 
tem with a target program loaded directly by PC DOS 
as in Fig. 1 A, and for a target program loaded by an em- 
bodiment of the present invention as in Fig. 1B. As 
shown in Fig. 2A, ROM occupies the upper portion of 
the memory address space with the remainder of mem- 
ory being filled up from the bottom: first the operating 
system 40 in lower memory, followed by device drivers 
and memory resident programs, then user selected pro- 
grams such as target program 50. Fig. 2B illustrates 
memory usage as in Fig. 2A, but additionally with mon- 
itor program 60 loaded. 

[0034] Fig. 3 illustrates the various CPU registers em- 
ployed by an 8086 type CPU, the general type of CPU 
employed by many personal computers, and for which 
the presently described preferred embodiment is intend- 
ed. Flags register 300 is a set of bit-wise flags the may 
be set or cleared during the execution of various types 
of instructions. These bits can be examined by other in- 
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structions to alter program flow or to perform other tasks. 
Registers 310 are general purpose and are used for a 
variety of tasks. Index registers 320 are typically used 
to indirectly reference memory. Stack pointer 330 is 
used to maintain a data storage stack in memory, in- s 
struction pointer (program counter) 340 points to the lo- 
cation in memory at which the next instruction to be ex- 
ecuted resides. Finally, segment registers 350 are used 
to prepend and additional 4 bits onto other memory ad- 
dressing registers (16 bits wide), allowing them to ac- w 
cess a broader range of memory. Because these regis- 
ters are intimately involved in the execution of programs, 
they are all emulated by the monitor program of the pre- 
ferred embodiment, so as to fully control the execution 
of a target program. 15 

Viral Code 

[0035] Fig. 4A illustrates the installation procedure 
typically employed by computer viruses. The virus exe- 20 
cution begins at block 400 and proceeds to block 410, 
at which the virus determines if a copy of itself has al- 
ready been installed in memory. If not, execution pre- 
cedes to block 420, where the virus the current value of 
interrupt vector 21 h (the operating system entry point 25 
on 8086 type computers), and saves this value for later 
use. Next, at block 430, the virus sets the entry point to 
point to a procedure within the virus itself, after which at 
block 440 control is passed to the host program. If at 
block 41 0 the virus had determined that a copy had pre- so 
viously been installed, control would pass immediately 
to block 440. 

[0036] Fig. 4B illustrates a typical viral procedure for 
replication. The beginning of such a procedure would 
be the replacement entry point stored by the viral code 35 
at step 430 of Fig. 4A. When a program later attempts 
to make an operating system call through int 21 , the call 
would be directed to beginning block 450 of the viral pro- 
cedure of Fig. 4B. The viral code would then execute, 
and at block 460 would determine if there was a file 40 
name associated with the operating system call. Such 
operating system calls are typically used by a normal 
program to open a file or execute another program. If 
there was a name associated with the operating system 
call, then at block 470 the viral code would replicate itself 45 
by writing its own executable code to the file that was 
the subject of the operating system call, in some instanc- 
es after having checked to ensure that this file was not 
already infected by the virus. After block 470, the viral 
code would then exit at block 480, passing control to the so 
original interrupt handler, a pointer to which had been 
saved at block 420 of Fig. 4A. If at block 460 the viral 
code had determined that there was no filename asso- 
ciated with the operating system call, then execution 
would have passed directly from block 460 to block 480. 55 
In this manner the operating system continues to func- 
tion normally except for a slight interruption while the 
viral code executes. 



Emulation to Detect Viral Code 

[0037] Fig. 5 illustrates the operation of monitor pro- 
gram 60 according to a preferred embodiment of the in- 
vention. The monitor program can be executed explicitly 
by the user with a designated target program, or in al- 
ternative embodiments can be executed automatically 
whenever an operating system call is placed to execute 
a program. At block 500, the monitor program loads the 
target program into memory, in exactly the same man- 
ner as the operating system would have loaded the tar- 
get program, but rather than passing execution to the 
target program immediately, the monitor program re- 
tains control for a period of time, to evaluate the target 
program. 

[0038] After the target program is loaded at block 500, 
at block 510 the monitor program initializes the emulat- 
ed registers, which correspond to the registers used by 
CPU 10. These register variables are used by a set of 
instruction emulation routines that are capable of emu- 
lating the instructions of CPU 10. The emulated regis- 
ters are initialized with the same values that the real reg- 
isters would have had if the target program had been 
loaded by the operating system for execution. 
[0039] After the emulation registers are initialized, the 
main emulation loop is entered. At block 520 the instruc- 
tion pointed to by the emulated program counter register 
is fetched by the emulation software and the emulated 
program counter register is incremented by the size of 
the fetched instruction, so that it points to the next in- 
struction. Control then proceeds to a set of evaluation 
procedures for the instruction. At block 530, the monitor 
program determines if the target program is attempting 
to access memory selected for controlled access. In the 
preferred embodiment, operating system procedures 
and data areas the address range of the monitor pro- 
gram are selected for controlled access. Optionally, any 
memory not belonging to the target program can be se- 
lected for controlled access. The memory access proc- 
ess is explained in more detail below with reference to 
Fig. 6. 

[0040] After block 530, at block 540 the monitor pro- 
gram evaluates the instruction for attempted access to 
a controlled procedure, explained more fully below with 
reference to Fig. 7, and then also emulates the execu- 
tion of the instruction. Following block 540 is block 550, 
at which the monitor program evaluates any possible 
modifications to the operating system entry points. The 
processes performed at block 550 are described in more 
detail below with reference to Figs. 8-10. 
[0041 ] Following the emulation and evaluation blocks 
530-550, at block 560 the monitor code determines if 
the target application has terminated. If so, emulation is 
terminated at block 570. The determination of step 560 
can be according to whether the target program termi- 
nates of its own accord, or the determination can be set 
by a total number of instructions to be emulated or by a 
fixed period of time for emulation. If the target program 
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has not terminated ot its own accord at step 560, and if 
the monitor program has not forcibly terminated it, con- 
trol returns to block 520, where the next cycle of the em- 
ulation loop is begun. The emulation termination at block 
570 includes some "cleanup" on the part of the monitor s 
program. This includes displaying to the user a status 
report of all operating system requests performed by the 
target program. This step may optionally also include 
reporting any memory accesses that have been per- 
formed outside of the area provided for the target pro- io 
gram by the monitor program. 

Controlling Access to Memory 

[0042] The memory access monitoring process of w 
block 530 is illustrated in further detail in Fig. 6. The de- 
scribed process involves remapping selected parts of 
memory, which effectively virtuaiizes those memory ar- 
eas, making them inaccessible to the target program, 
and thus protected. In alternative embodiments, access 20 
by the target program to these areas of memory is sim- 
ply denied by the monitor program. 
[0043] From the starting point at block 600, the pro- 
cedure passes to block 610, at which the monitor pro- 
gram determines if the current instruction is one whose 25 
function is to access memory. If so, then control passes 
to block 620, where the monitor program determines if 
the memory location to be accessed by the current in- 
struction is in an area selected for controlled access. If 
so, then control passes to block 630, which implements 30 
a remapping of the memory address. The monitor pro- 
gram's representation of the instruction is modified to 
point to the mapping destination, so that the original 
memory location is protected from the target program. 
[0044] In the preferred embodiment, the contents of 35 
the original memory location are copied to the mapping 
destination the first time the location is accessed by the 
target program. In other embodiments, the contents of 
the entire memory area selected for controlled access 
are copied into the mapping destination area when the 
monitor program first starts. In yet other embodiments, 
certain areas selected for controlled access can have 
their mapping destination areas initialized with null or 
dummy values. For example, it may be desirable that 
the content of the monitor program be protected and hid- « 
den from the target program, so that a virus cannot de- 
tect the presence of the monitor program. 
[0045] After the remapping of block 630, at block 640 
the attempted access to a controlled memory area is 
logged for later analysis and reporting to the user. After so 
block 640, the memory access control procedure ends 
at block 650, which returns control to the main process 
of Fig. 5, at block 540. A negative determination at either 
of blocks 610 or 620 also results in control passing im- 
mediately to block 650. 55 



Controlling Access to Procedures 

[0046] In some instances, it is desirable to control ac- 
cess to certain procedures. For instance, operating sys- 
tem procedures, ROM procedures, and interrupt han- 
dling procedures can have powerful effects and can be 
subject to misuse by a virus. For these reasons, it is de- 
sirable to control access to them and substitute special 
purpose procedures in their place, to encapsulate viral 
code within the emulated environment. 
[0047] After the memory access control procedure of 
block 530 of Fig. 5, control passes to block 540, which 
is illustrated in further detail in Fig. 7. From beginning 
block 700 control passes to block 71 0, at which the mon- 
itor program determines if the emulated program coun- 
ter points to a controlled procedure entry point; a list of 
such entry points is maintained by the monitor program. 
If so, then at block 720 the attempted access to a con- 
trolled procedure is noted. This can be by displaying a 
message to the user on the screen, writing to a log file, 
etc. 

[0048] Next, at block 730 the monitor program deter- 
mines if the instruction is to be directly emulated. This 
determination is made according to information stored 
for each controlled procedure entry point; for certain 
such procedures a special case emulation may be de- 
sired rather than directly emulating the instructions of 
the procedure. If the procedure is not to be directly em- 
ulated, then control passes to block 740, where a special 
case emulation of the entry point instruction is per- 
formed. In some instances this special case emulation 
will entail emulation of the entire controlled procedure 
at this point. 

[0049] If at block 730 it were determined that the con- 
trolled procedure was to be directly emulated, or if at 
block 71 0 it were determined that the emulated instruc- 
tion pointer did not indicate a controlled procedure entry 
point, then control would pass to block 750, where the 
instruction indicated by the emulated instruction pointer 
is emulated in the same manner as other instructions. 
Following the emulation according to either of blocks 
740 or 750, control passes to block 760, which returns 
execution to the main process of Fig. 5 

Controlling Access to Operating System Entry Points 

[0050] Block 550 is illustrated in further detail by Fig. 
8. This control of operating system entry points need not 
be performed to obtain substantial benefits from the em- 
ulation of the target program; however, this process 
does a higher level of control over the target program 
and also allows for a more accurate evaluation of viral 
behavior on the part of the target program. 
[0051] From beginning block 800 control passes to 
block 81 0, at which the monitor program examines a list 
of operating system entry points to determine if any have 
changed as a result of the instruction just emulated. This 
would indicate that the target program had replaced an 
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interrupt handler with a routine of its own. If there is such 
a change, then it is logged at block 820. At block 820 a 
flag is also preferable set to indicate that the entry point 
has changed, so that the change will not be logged re- 
dundantly later. In some embodiments, the flag indi- s 
cates the new value of the entry point, so the monitor 
program can determine if the entry point gets modified 
yet again. 

[0052] After block 820, at block 830 the emulated in- 
struction pointer, emulated code segment register, and io 
emulated flag register are saved onto the emulated 
stack. Then the emulated stack pointer is decremented 
the corresponding 6 bytes, in the same manner as if a 
hardware interrupt had been received. Next, at block 
840, the emulated code segment register and emulated *5 
instruction pointer are set to a special purpose monitor 
program routine to test the interrupt handler just in- 
stalled by the target program. This interrupt handler test- 
ing routine is described below with reference to Fig. 9. 
[0053] After block 840, execution passes to block 850, 20 
which returns control to the basic process of Fig. 5, This 
causes the interrupt handler routine of Fig. 9 to be em- 
ulated in the same step by step manner as the target 
program. This maintains the highest degree of encap- 
sulation around the target program, although if detecting 25 
viral replication is essentially the only concern, the in- 
terrupt handler testing routine of Fig. 9 may alternatively 
be executed in a more straightforward emulation without 
many of the execution safeguards described above. 
[0054] If at block 81 0 the monitor program had deter- 30 
mined that no operating system entry points had been 
changed, then control would have passed directly to 
block 850, and thus returned to the process of Fig. 5 to 
emulate the remainder of the target program. 

35 

Interrupt Handler Testing 

[0055] The basic tack of the interrupt handler testing 
routine is to offer up a guinea pig file for "sacrifice'' to a 
potential viral interrupt handler, and then test the guinea 
pig file for corruption. This requires that a "clean" guinea 
pig file already be at hand and also be disposable. This 
can be easily provided for by several methods, such as 
by creating the guinea pig file or copying the guinea pig 
file from a clean library copy at the very start of the mon- 4$ 
itor program. The guinea pig file should have a known 
content. It is preferably executable, but without its exe- 
cution involving writing to other files. The guinea pig file 
can thus be essentially a null file that does nothing when 
executed, simply returning immediately. 50 
[0056] As shown in Fig. 9, when the interrupt handler 
routine is entered at block 900, the first action is to open 
the guinea pig file, at block 91 0. after which the guinea 
pig file is closed at block 920. Next, at block 930 the 
interrupt handler testing routine examines the guinea & 
pig file to determine if its content has been changed. 
Such would be the result of a virus having contaminated 
the interrupt handlers for opening or closing files. If a 



change is not detected at block 930, then at block 940 
the guinea pig file is executed, after which at block 950 
the guinea pig file is again examined by the interrupt 
handler testing routine to determine if its content has 
been changed by the execution interrupt handler. 
[0057] If a positive determination had been made at 
either of blocks 930 or 950, then execution would pass 
from the respective block to block 960, at which the un- 
authorized access to the guinea pig file would be logged. 
After block 960, and also after a negative determination 
at block 950, execution passes to block 970, which ex- 
ecutes an (emulated) IRET instruction. This is a return 
from interrupt instruction, which causes the values 
placed onto the emulated stack at block 830 of Fig. 8 to 
be restored to the emulated registers. This completes 
the interrupt handler testing, and returns the emulation 
to its last point of emulation in the target program. 
[0058] For a more refined and definitive degree of 
analysis, block 960 can also initiate a routine to deter- 
mine not just if the guinea pig was contaminated, but if 
it was contaminated in a way so as to contaminate other 
files; i.e., if it was infected with viral replication behavior. 
Such a routine is illustrated in Fig. 10. The process of 
Fig. 1 0 essentially creates a completely new emulation, 
with the modified guinea pig file serving as the target 
program. If this first guinea pig file now passes modifi- 
cation behavior on to a second guinea pig file, then the 
original target program has been shown to be contami- 
nated with viral code having replicative behavior. To pre- 
vent needless additional recursion, the second level of 
emulation should be identified as such, through use of 
a flag, etc., so that if block 960 is reached during the 
second level of emulation, viral behavior is confirmed 
and the second level of emulation is terminated (rather 
than beginning another level of testing with yet another 
guinea pig file). 

[0059] This replication detection process is illustrated 
in Fig. 10. After beginning at block 1000, at block 1010 
the complete state of the current emulation is saved, and 
all operating system entry points, etc., are returned to 
their values at the beginning of the first emulation. Block 
1010 also then includes the step of initiating emulation 
again, but with the guinea pig file specified as the target 
program. As noted above, this emulation level should 
be flagged as a second level emulation. 
[0080] Block 1 020 indicates the point at which the em- 
ulation of the guinea pig file has terminated, after which 
at block 1040 the first level emulation determines if the 
emulated guinea pig file had written to a second guinea 
pig file. This determination is most straightforward if a 
flag is simply passed from the second level emulation 
back to the first; it can also be by examining a checksum 
for the file. If the determination is positive, then at block 
1 050 the initial target program is confirmed and logged 
as being virus-contaminated. At block 1060 at the end 
of the process of Fig. 1 0, control is passed back to block 
970 of Fig. 9, to continue emulation of the initial target 
program. Alternatively, reaching block 1050 can result 
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in the entire emulation being terminated, as the target 
program has been confirmed as being virus-contaminat- 
ed. 

Alternative Embodiments 5 

[0061 ] Rather than requiring the user to load the mon- 
itor program which then loads the target program, a "ze- 
ro length loader" TSR version could be installed in a sys- 
tem and every program requested to be executed could 10 
be emulated. If no abnormal behavior is found in the first 
'n' instructions, the monitor program could pass control 
to the CPU to allow the target to execute at lull speed" 
and the end user would not have to be aware of the ex- 
istence of the monitor program (other than a slight delay « 
during the initial execution). 

[0062] Another alternative approach would be where 
a recursive parser/emulator could effectively evaluate 
every single instruction of executable code in a program 
by noting the address of conditional branch instructions, 20 
and returning to that branch location, restoring the cpu/ 
memory state of the machine at that instant, and con- 
tinuing emulation as if the branch had taken the alter- 
nate route instead. Emulation continues until all instruc- 
tions have been evaluated. This would be a time con- 25 
suming process; however, the information revealed 
would definitively answer the question of whether the 
original code was virus infected. 
[0063] It is also important to note that, although the 
described embodiment is oriented towards identifying so 
viral behavior, the disclosed emulation techniques can 
be constructively employed to emulate program execu- 
tion in all types of situations where potentially destruc- 
tive or other predetermined program behavior is a con- 

35 

cem. 

[0064] It is to be understood that the above descrip- 
tion is intended to be illustrative and not restrictive. Many 
other embodiments will be apparent to those of skill in 
the art upon reviewing the above description. For in- 
stance, the instructions of the emulated application pro- *o 
gram could be read directly from disk storage rather than 
being loaded into memory first. The scope of the inven- 
tion should, therefore, be determined with reference to 
the appended claims, along with the full scope of equiv- 
alents to which such claims are entitled. 45 



Claims 

1. A computer system configured to monitor the exe- so 
cution of a target program, said computer system 
comprising: 

a processing unit having an instruction set; 

an instruction emulator for emulating instruc- 55 

tions corresponding to the instruction set; 

an entry point access controller for controlling 

access to operating system entry points; 



a logger for logging improper access by said 
instructions to operating system entry points; 
and 

an interrupt tester, wherein said interrupt tester 
executes a guinea pig file and tests for modifi- 
cation of the guinea pig file to determine if a viral 
interrupt has been installed. 

2. The computer system of claim 1 wherein said inter- 
rupt tester opens and closes a guinea pig file and 
tests for modification of the guinea pig file to deter- 
mine if a viral interrupt has been installed. 

3. The computer system of claim 1 wherein said inter- 
rupt tester executes the guinea pig file as a new tar- 
get program, thereby creating a second guinea pig 
file, and tests for modification of the second guinea 
pig file to determine if a replicative viral interrupt has 
been installed. 

4. The computer system of claim 1 further comprising 
a procedure access controller for controlling access 
to procedures during instruction emulation, wherein 
said logger logs improper access by said instruc- 
tions to procedures. 

5. The computer system of claim 1 further comprising 
a memory access controller for controlling access 
by said instructions to memory during instruction 
emulation wherein said logger logs improper ac- 
cess by said instructions to memory. 

6. A computer system configured to monitor the exe- 
cution of a target program, said computer system 
comprising; 

a processing unit having an instruction set; 
an instruction emulator for emulating instruc- 
tions corresponding to the instruction set; 
an entry point access controller for controlling 
access to operating system entry points; 
a logger for logging improper access by said 
instructions to operating system entry points; 
and 

an interrupt tester, wherein said interrupt tester 
opens and closes a guinea pig file and tests for 
modification of the guinea pig file to determine 
if a viral interrupt has been installed. 

7. The computer system of claim 6 wherein said inter- 
rupt tester executes the guinea pig file as a new tar- 
get program, thereby creating a second guinea pig 
file, and tests for modification of the second guinea 
pig file to determine if a replicative viral interrupt has 
been installed. 

8. The computer system of claim 6 further comprising 
a procedure access controller for controlling access 
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to procedures during instruction emulation, wherein 
said logger logs improper access by said instruc- 
tions to procedures. 

9. The computer system of claim 6 further comprising $ 
a memory access controller for controlling access 

by said instructions to memory during instruction 
emulation wherein said logger logs improper ac- 
cess by said instructions to memo 

10 

10. Method, in a computer system, for monitoring exe- 
cution of a target program comprising the steps of; 

- emulating instructions corresponding to the in- 
struction set of the target program; 15 

- controlling access to operating system entry 
points; 

- logging improper access by said instructions to 
operating system entry points; and 

monitoring emulation of the target program to 20 
detect a predetermined behaviour indicating 
presence of a virus, by: 

opening and closing a guinea pig file and 
testing for modification of the guinea pig file to 
determine if a viral interrupt has been installed. 25 

11. Method, in a computer system, for monitoring exe- 
cution of a target program comprising the steps of: 

- emulating instructions corresponding to the in- so 
struction set of the target program; 

- controlling access to operating system entry 
points; 

logging improper access by said instructions to 
operating system entry points; and 35 
monitoring emulation of the target program to 
detect a predetermined behaviour indicating 
presence of a virus, by: 

executing a guinea pig file and testing for 
modification of the guinea pig file to determine *o 
if a viral interrupt has been installed. 



PatentansprOche 
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1 . Computersystem, ausgelegt zur Uberwachung der 
AusfOhrung eines Targetprogramms, beinhaltend: 

eine Prozessoreinheit mit einem Befehissatz; 

einen Befehlsemuiator zum Emulieren der Be- so 

fehle entsprechend dem Befehissatz; 

einen Einsprungspunkt-Zugangscontroller zur 

Regelung des Zugriffs auf die Betriebssystem- 

Einsprungspunkte; 

einen Logger zum Protokollieren eines unbe- ss 
rechtigten Zugriffs auf die Betriebssystem-Ein- 
sprungspunkte durch Befehle; und 
einen Interrupt-PrOfer, wobei der Interrupt-Pru- 



fer eine Versuchdatei ausfQhrt und auf Ver&n- 
derungen prOft, urn herauszufinden, ob ein vi- 
raler Interrupt installiert wurde. 

2. Computersystem nach Anspruch 1 , wobei der Inter- 
rupt-PrOfer eine Versuchsdatei Gffnet und schiieBt 
und auf Ver§nderungen pruft, urn herauszufinden, 
ob ein viraler Interrupt installiert wurde. 

3. Computersystem nach Anspruch 1 , wobei der Inter- 
rupt-PrOfer eine Versuchsdatei als neues Tar- 
getprogramm ausfOhrt, wodurch eine zweite Ver- 
suchsdatei erfiffnet wird, und die zweite Versuchs- 
datei auf VerSnderungen pruft, urn herauszufinden, 
ob ein replikativer viraler Interrupt installiert wurde. 

4. Computersystem nach Anspruch 1, das zudem ei- 
nen Prozess-Zugangscontroller beinhaltet fOr die 
Regelung des Zugriffs auf die Prozesse bei der Be- 
fehlsemuiation, wobei der Logger einen unberech- 
tigten Zugriff auf die Prozesse durch diese Befehle 
protokolliert. 

5. Computersystem nach Anspruch 1 , das zudem be- 
inhaltet einen Speicher-Zugangscontroller zur Re- 
gelung des Zugriffs auf die Befehle des Speichers 
bet der Befehlsemulation. wobei der Logger einen 
unberechtigen Zugriff auf den Speicher durch diese 
Befehle protokolliert. 

6. Computersystem, ausgelegt zur Uberwachung und 
AusfOhrung eines Targetprogramms, beinhaltend: 

eine Prozessoreinheit mit einem Befehissatz; 
einen Befehlsemuiator zum Emulieren der Be- 
fehle entsprechend dem Befehissatz; 
einen Einsprungspunkt-Zugangscontroller zur 
Regelung des Zugriffs auf die Betriebssystem- 
Einsprungspunkte; 

einen Logger zum Protokollieren eines unbe- 
rechtigten Zugriffs auf die Betriebssystem-Ein- 
sprungspunkte durch diese Befehle; und 
einen Interrupt-PrOfer, wobei der Interrupt-PrO- 
fer eine Versuchsdatei dffnet und schiieBt und 
auf Veranderungen prQft, urn herauszufinden, 
ob ein viraler Interrupt installiert wurde. 

7. Computersystem nach Anspruch 6, wobei der Inter- 
rupt-PrOfer eine Versuchsdatei als neues Tar- 
getprogramm ausfOhrt, wodurch eine zweite Ver- 
suchsdatei eroffnet wird, und die zweite Versuchs- 
datei auf Veranderungen pruft, urn herauszufinden, 
ob ein replikativer viraler Interrupt installiert wurde. 

8. Computersystem nach Anspruch 6, das zudem be- 
inhaltet einen Prozess-Zugangscontroller zur Re- 
gelung des Zugriffs auf die Prozesse bei der Befehl- 
semulation, wobei der Logger einen unberechtigen 
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Zugriff auf die Prozesse durch die Befehle protokol- 
liert. 

9. Computersystem nach Anspruch 6, das zudem be- 
inhaltet einen Speicher-Zugangscontroller zur Re- s 
gelung des Zugriffs auf die Befehte des Speichers 
bei der Befehlsemulation, wobei der Logger einen 
unberechtigen Zugriff auf den Speicher durch die 
Befehle protokoliiert. 

10 

10. Verfahren in einem Computersystem zur Uberwa- 
chung und Ausf uhrung eines Targetprogramms, be- 
inhaltend die Schritte: 

Emulieren von Befehlen entsprechend dem 15 

Befehlssatz des Targetprogramms; 

Oberwachen des Zugriffs auf die Betriebssy- 

stem-Einsprungspunkte; 

Protokollierung eines unberechtigen Zugriffs 

auf die Betriebssystem-Einsprungspunkte 20 

durch die Befehle; und 

Oberwachen der Emulation des Targetpro- 
gramms, urn ein vorgegebenes Verhalten, wel- 
ches auf die Anwesenheit eines Virus hindeu- 
tet, zu erfassen, und zwar durch & 
6ffnen und SchlieBen einer Versuchsdatei und 
Prufen der Versuchsdatei auf Veranderungen, 
urn herauszufinden, ob ein viraler Interrupt in- 
stalliert wurde. 

30 

11. Verfahren zur Oberwachung der Ausf uhrung eines 
Targetprogramms in einem Computersystem, bein- 
haltend die Schritte; 

Emulieren von Befehlen entsprechend dem 35 

Befehlssatz des Targetprogramms; 

Oberwachen des Zugriffs auf die Betriebssy- 

stem-Einsprungspunkte; 

Protokollieren eines unberechtigen Zugriffs auf 

die Betriebssystem-Einsprungspunkte durch 

die Befehle; und 

Oberwachen der Emulation des Targetpro- 
grammes, urn ein vorgegebenes Verhalten, 
welches auf die Anwesenheit eines Virus hin- 
deutet, zu erfassen, und zwar durch *s 
Ausfuhren einer Versuchsdatei und PrQfen der 
Versuchsdatei auf Veranderungen, urn heraus- 
zufinden, ob ein viraler Interrupt installiert wur- 
de. 



Revendlcations 

1. Un systeme informatique configure pour contrdler 
I'execution d'un programme cible, ledit systeme in- & 
formatique comprenant : 

une unite de traitement presentant un jeu 



d'instructions ; 

un emulateur d'instructions pour 6muler des 
instructions correspondant au jeu 
d'instructions ; 

un organe de commande d'accfcs de points 
d'entree pour commander I'acces aux points 
d'entree du systeme Sexploitation ; 

un consignateur pour consigner un acces incor- 
rect, par lesdites instructions, aux points d'en- 
tree du systeme d'exploitation ; et 

un testeur d'interruption, ou ledit testeur d'inter- 
ruption execute un f ichier cobaye et teste pogr 
modification du fichier cobaye afin de determi- 
ner si une interruption virale s'est instance. 

2. Le systeme informatique de la revendication 1, 
dans lequel ledit testeur d'interruption ouvre et fer- 
me un fichier cobaye et teste pour modification du 
fichier cobaye afin de determiner si une interruption 
virale s'est installee. 

3. Le systeme informatique de la revendication 1, 
dans lequel ledit testeur d'interruption execute le fi- 
chier cobaye en tant que nouveau programme cible, 
en errant ainsi un second fichier cobaye, et teste 
pour modification du second fichier cobaye afin de 
determiner si une interruption virale duplicative 
s'est installed. 

4. Le systeme informatique de la revendication 1, 
comprenant en outre un organe de commande d'ac- 
ces protocole pour commander I'acces a des pro- 
tocoles pendant I'emulation des instructions, ou le- 
dit consignateur consigne un acces incorrecte, par 
lesdites instructions, aux protocoles. 

5. Le systeme informatique de la revendication 1, 
comprenant en outre un organe de commande d'ac- 
ces m6moire pour commander I'acces, par lesdites 
instructions, a la memoire pendant i'emulation des 
instructions ou ledit consignateur consigne un ac- 
ces incorrecte, par lesdites instructions, a la m6moi- 
re. 

6. Un systeme informatique configure pour contrdler 
I'execution d'un programme cible, ledit systeme in- 
formatique comprenant : 

une unite de traitement presentant un jeu 
d'instructions ; 

un emulateur d'instructions pour emuler des 
instructions correspondant aux jeux 
d'instructions ; 
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un organ e de commande d'acc&s de points 
d'entree pour commander I'acces aux points 
d'entree du systeme d'exploitation ; 

un consignateur pour consigner un acces incor- 
rect, par lesdites instructions, aux points d'en- 
tree du systeme d'exploitation ; et 

un testeur d'interruption, oD ledit testeur d'inter- 
ruption ouvre et ferme un fichier cobaye et teste 
pour modification du fichier cobaye afin de de- 
terminer si une interruption virale s'est instal- 
ls. 

7. Le systeme informatique de la revendication 6 t 
dans lequel ledit testeur d'interruption execute le fi- 
chier cobaye en tant que nouveau programme cible, 
en errant ainsi un second fichier cobaye, et teste 
pour modification du second fichier cobaye afin de 
determiner si une interruption virale duplicative 
s'est instance. 

8. Le systeme informatique de la revendication 6, 
comprenant en outre un organe de commande d'ac- 
c6s protocole pour commander I'acces a des pro- 
tocols pendant ('emulation des instructions, oil le- 
dit consignateur consigne un acces incorrecte, par 
lesdites instructions, aux protocoles. 

9. Le systeme informatique de la revendication 6, 
comprenant en outre un organe de commande d'ac- 
c£s memoire pour commander I'acces, par lesdites 
instructions, & la memoire pendant remulation des 
instructions oCi ledit consignateur consigne un ac- 
ces incorrecte, par lesdites instructions, a la memoi- 
re. 

10. Un proc6de pour contrdler, dans un systeme infor- 
matique, I'execution d'un programme cible compre- 
nant ies etapes consistant a : 

- emuler des instructions correspondant au jeu 
^instructions du programme cible ; 



11. Un proc6de pour contrdler, dans un systeme infor- 
matique, 1'execution d'un programme cible compre- 
nant Ies etapes consistant a : 

5 - emuler des instructions correspondant au jeu 
destructions du programme cible ; 

commander I'acces aux points d'entree du sys- 
teme d'exploitation ; 

consigner un acces incorrecte, par lesdites ins- 
tructions, aux points d'entree du systeme 
d'exploitation ; et 

contrdler ['emulation du programme cible pour 
detecter un comportement predetermine indi- 
quant la presence d'un virus, en : 
executant un fichier cobaye et en testant pour 
modification du fichier cobaye afin de determi- 
ner si une interruption virale s'est install6e. 
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commander I'acces aux points d'entree du sys- 45 
teme d'exploitation ; 

consigner un acces incorrecte, par lesdites ins- 
tructions, aux points d'entree du systeme 
d'exploitation ; et so 

contrdler l'6mulation du programme cible pour 
detecter un comportement predetermine indi- 
quant la presence d'un virus, en : 
ouvrant et fermant un fichier cobaye et en tes- ss 
tant pour modification du fichier cobaye afin de 
determiner si une interruption virale s'est ins- 
tate. 
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